…asticsearch work processing

So that order of LuceneWorks for a given class relative to those for
another class is preserved upon successive runs, and is the same from
one machine to another.

This should not change much feature-wise, but should make debugging much
easier in the future.

So that relative order of LuceneWorks for a given class is preserved
upon successive runs, and is the same from one machine to another.

This should not change much feature-wise, but should make debugging much
easier in the future.

Inheritance is already handled at a higher level by creating multiple
purge works.

Rationale: in our case, Elasticsearch is not our source of truth, some
other component (traditionally a database) is. When we perform a
delete-by-query, it's only to do an index purge, and rebuild the index
after that.
If there is a write to the index concurrently to the purge, it's
generally no big deal: it mainly means the document will be reindexed
just a moment later.

This should avoid *some* cases where delete-by-query failed due to a
version conflict: those cases where the update was performed
strictly before the delete-by-query (for instance by the same thread).

…ple conflicting purges without refreshes

…ple conflicting writes without refresh